In one way or another, DEC has always been there at critical moments in computer history. (You may recall that Ken Thompson was first hacking UNIX on a DEC PDP-10.)
This link will take you to Lawrence Crowl's wonderful computer history page, which shows photographs of machines that mark milestones in our computer culture (starting with the very first computer ever constructed by Charles Babbage, circa 1823). The first DEC PDP-1 appears on that page.
Cross Reference: To appreciate just how long DEC has been delivering computer products to the industry, take a moment to catch this link: http://www.cs.orst.edu/~crowl/history/.
The machine looked, quite frankly, like a prop in some terrible B movie from the 1950s--something you would expect to see in the laboratory of a mad scientist. Incredibly, there was a time when such "technology" was the state of the art. Well, DEC moved on pretty quickly, to produce a wide range of products, including the very first minicomputer, the DEC PDP-8.
Cross Reference: To get a full-screen view of that machine, catch this link: http://www.cs.orst.edu/~crowl/history/dec_pdp1_2.full.jpg.
In 1978, DEC created the first VAX (virtual address extension), the Digital VAX 11/780. This machine offered 32-bit architecture and 1MIPS performance. By standards of the day, the 11/780 was powerful and fast. (It was also backward compatible with the PDP line that preceded it.) The pricetag? A mere $200,000.
Cross Reference: You can see this machine on Crowl's page as well, located full size at http://www.cs.orst.edu/~crowl/history/dec_pdp8.full.jpg.
Curiously, the 11/780 became so popular that it would establish itself as the benchmark for the MIPS index. In other words, it became the yardstick by which to measure performance of all workstations that later followed. (This occurred despite the fact that the IBM 370/158 was reportedly comparable in terms of speed and processing power. For reasons unknown to me, the IBM 370/158 never reached the popularity status of the 11/870.)
NOTE: MIPS refers to million instructions per second.
So, to reiterate, the 11/870 was a $200,000 machine that could do roughly 1 million instructions per second. Fantastic. Today, if you were to advertise this machine for sale on the Internet, you would have to pay the buyer to haul it away. It is considered by today's standards either junk or, perhaps more charitably, a collector's item. However, one thing made the 11/870 a special innovation and still singles it out from other machines in computer history: The 11/870 could support two operating systems. One was a system--UNIX--that was known reasonably well at the time. The other system was something a little different. It was called VMS. We will be examining VMS in just a moment. First, however, I want to give you an idea of what the VAX was all about.
The VAX was a multiuser system. Many readers may not be old enough to remember the VAXstations, so I'll offer a little description. The MicroVAX stands nearly 3 feet tall. On the right side of the machine is a panel that, when opened, reveals the cards. These cards are quite large, although not nearly as large as the panels of, say, a SPARCstation 4/330 VME deskside computer. (But certainly larger than most modern motherboards for personal computers.)
The Terminal is a VT220, with a viewing screen of approximately 81/2 inches. At the back of the terminal are various connectors. These include a data lead connection, a printer connection, and a serial port. The serial port could be set to an amazing 19200 baud and terminal emulations available included VT220 and VT100. If you connect a modem to the terminal, you have to set modem commands by hand. (In other words, you would have to send raw modem commands from a blank screen that sports a blinking cursor. Typically, you would dial by issuing the command ATDT5551212, for example.)
Contained within the terminal is firmware. This is software hard-coded into the board itself. (PC users should think of firmware in exactly the same way as the CMOS. It is a small software module that performs a limited number of tasks, including setting the machine's parameters.) Unfortunately, there is no facility by which to capture a figure of the screen, so I must describe it. When the terminal boots, you are presented with a copyright screen and then a blank screen with a blinking cursor. The terminal is then ready to accept commands. To manipulate the settings in the firmware, you choose the F3 (function 3, or Setup) key. This brings up a menu at the bottom of the screen, where you can review and change various settings. These include not only the way that communications are conducted, but also how the screen is laid out and behaves. For example, you have a choice of either an amber background and black foreground or the reverse. You can specify a typewriter keyboard or Data mode, which is more commonly used when interfacing directly with the VAX. You can also manipulate the number of characters per line and lines per screen. (Additionally, the firmware has short help messages embedded within it. These generally appear at the bottom of the screen, in the status area, as do the setting values for each facet of your environment. These may indicate which printer you are using, whether you want local echo, whether you want type-ahead mode, and so forth.) No mouse, hard disk drive, floppy drive, or other components are either present or required.
You have a wide range of choices regarding communication. For example, you can change the bits (typically 7 or 8) and also the parity of these (none, odd, even). This makes the VT220 terminal valuable not only to interface with VAXen (slang for VAX machines), but also a wide variety of UNIX machines. For example, you can use a VT220 terminal as a "head" for a workstation that otherwise has no monitor. This can generally be done by plugging the terminal into the first serial port of the workstation. (For most versions of UNIX, you generally need to strip the eighth bit.)
These terminals, while intended for use with the VAX, can also be used as the most inexpensive method ever of accessing the Internet. Naturally, you need an old-style dial-up connection to do so (perhaps via Delphi), but there is no comparison in the price. Such terminals can now be purchased for $20. Add to this the price of a 19200 baud modem, and you are done. They are also great for connecting to local BBSs.
TIP: For Linux hackers: You can also "add" an Internet node to your box using such a terminal. To do so, you plug the terminal into either COM1 or COM2. You then edit inittab to respawn another instance of getty on that port. For this to work, you need to ensure that the cable used is a null modem cable. You also should set the emulation to VT100. When the Linux box reboots, a login prompt will appear on the VT220. From there, log in as any valid user, and you are ready. This is significantly valuable, especially if you are trying to train someone in programming or navigation of the Net via a CLI (command-line interface). It is important to note that if you are using the same COM port that normally supports your mouse, you need to kill gpm (general purpose mouse support).
These terminals are used to connect to the VAX. (Note, too, that I have described only very early implementations of VT terminals. Much later models supported various types of colors and graphics not available to the early VT100 and VT220 terminals. These newer models are extremely functional but can run as high as several hundred dollars. Good examples are the VT330 and VT340.)
TIP: An interesting point here: Such a terminal does not have environment variables per se and therefore reports none. All the environment variables are obtained from whatever shell you happen to acquire on the remote machine.
Finally, you can connect to a VAX without such a terminal. Typically, this is done using PC software that supports VT100 terminal emulation. (Kermit is another popular and compatible emulation.)
Some common VMS commands are listed in Table 19.1.
| Command | Purpose |
| HELP [args] | If issued alone (without arguments), this command will bring up the prompt Topic?. The HELP command is generally followed by whatever command you want to learn about. |
| COPY [arg1 arg2] | Will copy an existing file or files to another file or directory. |
| DIRECTORY | Works very much like the DOS command dir, giving the contents of a directory and the attributes associated with the files therein. |
| Invokes the e-mail program interface for VAX. This works (roughly) like standard mail in UNIX. When preparing to compose a message, you are prompted for recipient and subject. | |
| LOOK | The VAX equivalent to the UNIX command ps, LOOK shows you your current processes. |
VMS has many of the amenities of other operating systems. The commands may be just slightly different. For example, the C shell in UNIX has a facility that will recall commands previously typed at the prompt. This facility is called history. (DOS has a similar command module, usually loaded at boot time, called DOSkey.) In VMS, you can recall commands recently typed by holding down the Ctrl key and the letter B. There are other key combinations that will stop a process, list all processes, resume a process, report current user statistics, and edit the current command line.
TIP: There is a nice table of command translations from VAX to UNIX. The table has been around for a while and basically offers UNIX users and others a brief reference. It is located at http://egret.ma.iup.edu/~whmf/vms_to_unix.html. You might want to examine that table now, because I will refer to a few of those commands throughout this chapter.
There are still many VAX servers on the Internet, and VMS is still very much alive. The newest version is called OpenVMS. OpenVMS is available for both VAX and Alpha machines. Alphas are extremely fast workstations (now at speeds exceeding 400Mhz) that can run Windows NT, OpenVMS, or Digital UNIX.
The majority of VAX servers on the Net are older. Many are machines located at university libraries. These provide users with facilities for searching electronic card catalogs. In all likelihood, most older VAX machines are at least as secure as their UNIX workstation counterparts. This is because much is known about the VAX/VMS system and its security. If there is a hole, it is because the system administrator missed it.
TIP: There is a complete online manual on OpenVMS. It is almost 1MB, but offers comprehensive coverage of OpenVMS and its capabilities. That document is available at http://www.ethz.ch/ETH/ID/KS.html.docs/SW_Distr/OpenVMS_AXP_Distr/9506-OpenVMS_AXP_new_features.html.
This document is one of the definitive texts on cracking the VMS system. It was authored by Lex Luthor (an alias, of course), who in 1984 established a bulletin board called the Legion of Doom. From this (and through other means) Luthor gathered together a loosely knit cracker group that went by the same name. Legion of Doom (or LoD, as they are more commonly referred to) pulled off some of the most extraordinary cracks ever done. LoD published many electronic journals on the Internet that simplified the art of cracking, including the LoD Technical Journal. The federal government waged a fleetingly successful war against members of the group. Today, former LoD members are a little piece of Internet folklore.
Cross Reference: The previous paragraph is excerpted from Lex Luthor's "Advanced Hacking VAX's VMS" (Legion of Doom, June 1, 1985). It can be found online at http://www.mdc.net/~trent/hackvax.txt.
Attacking a VAX (or any VMS-based system) is quite different from attacking a UNIX system. First, the concept of the password file is different and so is its structure. UNIX systems maintain /etc/passwd, which defines the username, password, login shell, and group. In contrast, the VMS system uses a file that defines many other variables, not simply these values:
Cross Reference: Perhaps one of the best documents available on the Internet for information on how to secure a VMS box was written by neither a cracker nor a hacker: Rob McMillan, "A Practical Exercise in Securing an OpenVMS System," Prentice Centre, The University Of Queensland, http://nsi.org/Library/Compsec/openvms.txt.
Note that this "comprehensive" approach to the password file has its pitfalls. One is this: If a cracker gains access to the file and cracks it (using the utilities described later in this chapter), the whole system is subject to breach, then and there. However, the likelihood of that happening is poor.
Cross Reference: The previous paragraph is excerpted from "The Five Minute Guide to VMS Security: Product Review PC-DEC-AUDIT" (AudIT Magazine, 1994). It can be found online at http://www.trillion.demon.co.uk/magrev.htm.
The user, by the way, is identified through the use of a user identification code (UIC). This is very similar in ways to the GID in UNIX. It identifies the user and what groups that user may belong to. As you might have guessed, the UIC comes from the centralized database:
Cross Reference: The previous paragraph is excerpted from "OpenVMS Guide to System Security: Contents of a User's Security Profile. 4.1.1.3 How Your Process Acquires a UIC," which can be found online at http://wawona.ethz.ch/OpenVMS_docu/ssb71/6346/6346p004.htm#heading_4.1.1.
This was a local problem and not a particularly critical one. For specific information on that hole (and the fix), obtain the Defense Data Network Advisory concerning it.
Cross Reference: The previous paragraph is excerpted from a CERT advisory titled "VMS Monitor Vulnerability." It can be found online at http://www.arc.com/database/Security_Bulletins/CERT/CA-92:16.VMS.Monitor.vulnerability.
Cross Reference: The Defense Data Network Advisory concerning this hole is located at DDN Security Bulletin 9223, ftp://nic.mil/scc/sec-9223.txt.
In that advisory, an analysis of the worm was provided by R. Kevin Oberman of the Engineering Department of Lawrence Livermore National Laboratory. Oberman's report was apparently generated on-the-fly and in haste, but it was quite complete notwithstanding. He reported that the worm was not incredibly complex but could be dangerous if it compromised a privileged account. The worm would enter a system, check to see if it was already infected, and if not, perform some or all of these procedures:
Cross Reference: The previous paragraph is excerpted from a CERT advisory titled "`WANK' Worm On SPAN Network." It can be found online at http://www.arc.com/database/Security_Bulletins/CERT/CA-89:04.decnet.wank.worm.
What's really interesting is the degree of seriousness in the tone of the advisory. Think about it for a moment. It was just less than one year before that the Morris Worm incident sent a ripple through the Net. The mere mention of a worm during those months could cause a panic. Oddly, though, because of the curious name of this particular worm, some administrators initially took the warnings for a joke.
Cross Reference: The main advisory, issued by CERT is located at http://www.arc.com/database/Security_Bulletins/CERT/CA-89:04.decnet.wank.worm.
Also, the Wank Worm was irrelevant to a large portion of the Internet. Since the worm only affected those running DEC protocols (and not TCP/IP), only a limited number of potential victims existed. However, while that number was relatively small in proportion to the entire Internet, there were a great many sites using DecNet.
An interesting treatment of the event can be found in "Approaching Zero: The Extraordinary Underworld of Hackers, Phreakers, Virus Writers, and Keyboard Criminals":
Cross Reference: The previous excerpt is from an article by Paul Mungo and Bryan Glough titled "Approaching Zero: The Extraordinary Underworld of Hackers, Phreakers, Virus Writers, and Keyboard Criminals." It can be found online at http://www.feist.com/~tqdb/h/aprozero.txt.
That minimum, however, can be quickly surpassed if need be. The system operator can apply special access controls on individual files and directories, a user account, or processes. When undesirable or suspicious activity occurs in relation to these access control policies, an alarm is generated. The system operator defines what form the alarm will take. (For example, it is common for system operators to redirect alarm information to a specific console so that such messages visibly appear and can be quickly perused at any time.) Of course, severe paranoia in this type of environment can add up to sacrificing a fair amount of disk space. For example, a system operator can even have the system generate alarms on a mere attempt to access a file for which the user has no privileges.
An example would be where a user attempted to view (or list) a file for which he had no privileges. It would be the equivalent of issuing an alarm for each time a shell user on a UNIX system tried accessing a root-owned file or directory. One interesting thing about this is that the alarm can be generated in response to a violation of policies set against the user, as opposed to global restrictions placed on the file. I am not sure which model is actually more secure, but I would guess it would be the VMS model.
The logging capabilities of VMS are quite granular. You can monitor almost anything from users accessing a file to them starting a protocol-based process. (You can even log users attempting to change the time.) In addition to this native monitoring, there are several utilities (some of which I mention later in the chapter) that can trap terminal sessions and monitor them for inactivity and perhaps other undesirable behavior.
Various utilities make it easier to crack the VMS platform or, having cracked it, to avoid detection. As with any other system, these utilities are sometimes of significant advantage to both the root operator and the cracker.
Cross Reference: The source code and full explanation of watchdog.com are located at http://www.wordserf.co.uk/mh/vaxhackpro.html.
Cross Reference: The source code for Stealth is at http://www.wordserf.co.uk/mh/vaxhackpro.html.
Cross Reference: GUESS_PASSWORD (with source) is available at http://www.uniud.it/ftp/vms/uaf.zip.
Cross Reference: WATCHER is available at ftp://ftp.wku.edu/madgoat/WATCHER.zip.
Cross Reference: Checkpass is available at ftp://www.decus.org/pub/lib/vs0127/checkpass/check.zip.
Cross Reference: The CRYPT utility is located at ftp://www.decus.org/pub/lib/vs0127/crypt/crypt.zip.
Cross Reference: DIAL is available at ftp://www.decus.org/pub/lib/v00149/dial.zip.
Cross Reference: CALLBACK.EXE is available at http://www.openvms.digital.com/cd/CALLBACK/CALLBACK.EXE.
I should point out that the term calls means outgoing TCP/IP connect requests. That is, you can restrict connect requests to specific IP addresses, based on user information in the Access Control List. A pretty nifty utility. For example, you could restrict any access to outside hacker or cracker boards. Hmm.
Cross Reference: The previous paragraph is excerpted from a file titled TCPFILTER.DOC ENGLISH by G. Gerard. It can be found online at http://www.openvms.digital.com/cd/TCPFILTER/.
Cross Reference: TCPFILTER is located at http://www.openvms.digital.com/cd/TCPFILTER/TCP.COM.
Because Digital Alpha stations now run both Microsoft Windows NT and Digital UNIX, VMS is likely to take a backseat. This is especially so with regard to Digital UNIX because it is a 64-bit system. Imagine for a moment a 64-bit system running at 400MHz. In my opinion, this configuration is the most powerful currently available to the average user. Such a machine (loaded with at least 64MB of RAM) is vastly superior in my opinion to either the Pentium or the MMX. So the days of the old VAX/VMS are probably over.
Today's cracker probably knows little about these systems. More concentration has been allotted to UNIX and as of late, Windows NT. If I were going to contract someone to crack a VAX, I would look for someone in his mid-30s or older. Certainly, the advent of the PC has contributed to the lack of VMS security knowledge. Young people today work mostly with PC- or Mac-based machines. It is therefore rare to come in contact with a VAX anymore, except as library servers or other database machines.
A close friend of mine has a MicroVAX II in his garage. Each time I visit his home, we talk about the prospect of cranking up that old machine. One day soon, we'll probably do just that.
At day's end, VMS is an interesting, durable, and relatively secure platform. Moreover, DEC was always exceptionally close-mouthed about the security weaknesses of VAX/VMS. If you retrieve all the known advisories on VAX/VMS, you will see that DEC routinely declined to include information that could potentially be used by crackers. (Most often, DEC would advise that VAX users contact their local DEC representative.) This was a smart move and one that has made it traditionally difficult to crack VAX servers. If the system administrator of a VAX has been on his toes, after a cracker has tried all the default passwords, there is nothing left to do but turn to social engineering.
In closing, it is my opinion that the security of the VAX is advanced and even somewhat elegant. Moreover, in many parts of the world, the VAX is still popular. Time studying VAX security is probably time well spent.
A Retrospective on the VAX VMM Security Kernel. Paul A. Karger, Mary E. Zurko, Douglas W. Bonin, Andrew H. Mason, and Clifford E. Kahn. IEEE Transactions on Software Engineering, 17(11):1147-1163, November 1991.
Database Security. S. Castano, M. G. Fugini, G. Martella, and P. Samarati. Addison-Wesley Publishing Company. 1995. (Good chapter on VAX/VMS.)
Security Guidance for VAX/VMS Systems. Debra L. Banning. Sparta, Inc. 14th National Computer Security Conference, Washington, DC, October, 1991.
A Practical Exercise in Securing an OpenVMS System. Rob McMillan, Prentice Centre, The University Of Queensland.
How VMS Keeps Out Intruders. Tanya Candia. Computers & Security, 9(6):499-502, October 1990.ESNET/DECNET Security Policy Procedures and Guidelines. D. T. Caruso and C. E. Bemis, Jr., ESnet/DecNet Security Revised Draft, December 1989.
C.O.T.S. (Certified OpenVMS Technical Specialist) Examination. Approaching Zero: The Extraordinary Underworld of Hackers, Phreakers, Virus Writers, and Keyboard Criminals. Paul Mungo and Bryan Glough. VMS Monitor Vulnerability. CERT advisory. CA-92:16. September 22, 1992.
© Copyright, Macmillan Computer Publishing. All rights reserved.